Skip to content

feat(config): add customGetElementError config option #452

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

aw-davidson
Copy link
Contributor

@aw-davidson aw-davidson commented Feb 12, 2020

Closes #360

What:
Adding a showLogOnFail option to configure logging for getBy* and getAllBy* when the query fails.

Why:
Logging the entire document when working with larger components can obscure other error messages. I often find these explicit error messages are more helpful than scrolling through the output from prettyDom. If the DOM needs to be examined then debug() can be used. @benmonro also mentions that this makes working with Testcafe harder.

How:
getElementError looks at the config and determines what to output as an error:

function getElementError(message, container) {
  const errorMessages = getConfig().showLogOnFail
    ? [message, prettyDOM(container)]
    : [message]
  return new Error(errorMessages.filter(Boolean).join('\n\n'))
}

Checklist:

@codesandbox-ci
Copy link

codesandbox-ci bot commented Feb 12, 2020

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 31040e5:

Sandbox Source
adoring-liskov-6v6yb Configuration

@codecov
Copy link

codecov bot commented Feb 12, 2020

Codecov Report

Merging #452 into master will not change coverage by %.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##            master      #452   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           22        22           
  Lines          385       385           
  Branches        91        91           
=========================================
  Hits           385       385           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf57dcd...31040e5. Read the comment docs.

@aw-davidson aw-davidson changed the title feat(config): add showLogOnfail config option to configure feat(config): add showLogOnfail config option Feb 12, 2020
Copy link
Member

@benmonro benmonro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd use the queries object so the list of queries doesn't need to be maintained. the other comment is a total nit. :)

@aw-davidson aw-davidson force-pushed the pr/log-output-on-fail-option branch from a8362cb to 4b2228e Compare February 17, 2020 15:12
@aw-davidson aw-davidson requested a review from benmonro February 17, 2020 15:15
(query, showLogOnFail) => {
configure({showLogOnFail})
document.body.innerHTML = '<div>Hello</div>'
expect(() => screen[query]('TEST QUERY')).toThrowErrorMatchingSnapshot()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer tests that specifically look for the presence/absence of the error message (not a fan of snapshot tests personally) but I'm not gonna block for it. I'll defer to @kentcdodds or someone else on that.

Copy link
Contributor Author

@aw-davidson aw-davidson Feb 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this?

const div = '<div>Hello</div>'
document.body.innerHTML = div
try {
    screen[query]('TEST QUERY'))
} catch (err) {
    expect(err.message.includes(div)).toBe(showLogOnFail)
}

benmonro
benmonro previously approved these changes Feb 17, 2020
Copy link
Member

@benmonro benmonro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me. I'll defer to @kentcdodds though on the snapshot tests

@benmonro
Copy link
Member

benmonro commented Feb 17, 2020 via email

Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really find myself using this option. In CI you want it anyway and during dev most of the time as well. I hold off voting for this one.

@benmonro
Copy link
Member

benmonro commented Mar 3, 2020

@eps1lon this is specifically useful in e2e tests where logging the entire Dom is never going to be useful. Even in CI I'd say you don't want it as the Dom will usually be higher than the limit anyway. In RTL tests sure but for testcafe, Cypress etc full Dom logging Is just noise.

@benmonro
Copy link
Member

benmonro commented Mar 3, 2020

@kentcdodds any objections to merging this?

Copy link
Member

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me. Just one thing, then anyone can feel free to merge.

kentcdodds
kentcdodds previously approved these changes Mar 3, 2020
Copy link
Member

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super. Thank you!

@benmonro
Copy link
Member

benmonro commented Mar 3, 2020

👍

benmonro
benmonro previously approved these changes Mar 3, 2020
@kentcdodds
Copy link
Member

Hold it. Hmm.... I just had an idea.

What if we invert control and instead hand the logging responsibility to you if you want it.

@kentcdodds
Copy link
Member

So something like:

config.customGetElementError((message, container) => {
  // do whatever. So to support what you want here it'd be:
  return new Error(message)
})

I think I'd be happier with that :)

@aw-davidson
Copy link
Contributor Author

@kentcdodds, Ok. I'll try implementing that

@aw-davidson aw-davidson dismissed stale reviews from benmonro and kentcdodds via 997bda7 March 3, 2020 21:51
@aw-davidson aw-davidson force-pushed the pr/log-output-on-fail-option branch from 9cc7ce9 to 997bda7 Compare March 3, 2020 21:51
@aw-davidson aw-davidson force-pushed the pr/log-output-on-fail-option branch from 997bda7 to 1be0482 Compare March 3, 2020 22:04
Comment on lines 8 to 10
const errorMessages = [message, prettyDOM(container)]
if (customGetElementError) {
return customGetElementError(...errorMessages)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd prefer it if it were this way:

Suggested change
const errorMessages = [message, prettyDOM(container)]
if (customGetElementError) {
return customGetElementError(...errorMessages)
}
if (customGetElementError) {
return customGetElementError(message, container)
}
const errorMessages = [message, prettyDOM(container)]

That way the developer writing their custom error getter can pretty-ify the container if they want, but they can do something else with it if they'd rather.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that too, but I wasnt sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kentcdodds just updated with that last suggestion and rebased.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that!

One other thing, with this now I think we can make things even better. It's hard to explain so I hope you don't mind if I make the change myself and you can ask me questions/provide feedback if you have any.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that refactor makes sense

@aw-davidson aw-davidson force-pushed the pr/log-output-on-fail-option branch from 1be0482 to 8b8307a Compare March 4, 2020 01:17
@aw-davidson aw-davidson changed the title feat(config): add showLogOnfail config option feat(config): add customGetElementError config option Mar 4, 2020
@kentcdodds kentcdodds merged commit d6d41f9 into testing-library:master Mar 4, 2020
@kentcdodds
Copy link
Member

🎉 This PR is included in version 6.13.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@kentcdodds
Copy link
Member

@all-contributors please add @aw-davidson for code and tests

@allcontributors
Copy link
Contributor

@kentcdodds

I've put up a pull request to add @aw-davidson! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ability to suppress logging full DOM
4 participants